ElastiCacheのオートディスカバリを目で見てみる

ElastiCacheのオートディスカバリを目で見てみる

Clock Icon2014.07.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本日発表された新機能で、ElastiCacheのmemcacheエンジンで複数AZに分散したクラスタグループを作成することが出来るようになりました(【ElastiCache】memcachedのMulti-AZ構成が来ました!!! | Developers.IO)

今までのようにそれぞれのAZに別々のキャッシュクラスタを作る事無く、一つのキャッシュクラスタでAZを分散してキャッシュノードを配置することに出来ます。AZ分散したオートディスカバリが使えるということですね。

そこで改めてオートディスカバリについて調べてみました。

オートディスカバリ

オートディスカバリとは、複数のキャッシュノードのそれぞれのエンドポイントを意識せず使うための機能です。具体的には、ElastiCacheクラスタには、クラスタを示すユニークなコンフィグレーションエンドポイントを持っています。

cf00

このコンフィグレーションエンドポイントは、常に少なくとも1つのキャッシュノードを指しています。例えばコンフィグレーションエンドポイントが「smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com」で、ノード数が2つの場合、各エンドポイントをdigしてみると

$ dig smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com

;; ANSWER SECTION:
smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com. 60 IN	A 172.31.11.218

$ dig smokeycache.16bbhn.0001.apne1.cache.amazonaws.com

;; ANSWER SECTION:
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com. 60 IN A 172.31.22.213

$ dig smokeycache.16bbhn.0002.apne1.cache.amazonaws.com

;; ANSWER SECTION:
smokeycache.16bbhn.0002.apne1.cache.amazonaws.com. 60 IN A 172.31.11.218

のように返ってきましたので、この時点でのコンフィグレーションエンドポイントは、0002のキャッシュノードを指していることになります。もし0002のキャッシュノードが削除された場合にはまた別のキャッシュノードのIPアドレスを指します。つまり「コンフィグレーションエンドポイントに繋げば、必ずキャッシュクラスタに所属しているどれかのキャッシュノードに接続出来る」わけですね。

そして、コンフィグレーションエンドポイントに接続してconfig get clusterコマンドを実行することで、そのキャッシュクラスタに所属しているノードの一覧を取得することが出来ます。

$ telnet smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com 11211
Trying 172.31.11.218...
Connected to smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com.
Escape character is '^]'.
config get cluster
CONFIG cluster 0 142
1
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com|172.31.22.213|11211 
smokeycache.16bbhn.0002.apne1.cache.amazonaws.com|172.31.11.218|11211

END

現時点では以下のように2台のキャッシュノードがあります。[Add Node]からキャッシュノードを1台追加してみます。

cf01

キャッシュノードが3台になりました。

cf02

すると、config get clusterコマンドの結果として、3台のノードクラスタの情報が返ってきます。

config get cluster
CONFIG cluster 0 211
2
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com|172.31.22.213|11211 
smokeycache.16bbhn.0002.apne1.cache.amazonaws.com|172.31.11.218|11211 
smokeycache.16bbhn.0003.apne1.cache.amazonaws.com|172.31.3.104|11211

END

次に、[Delete Node]ボタンからキャッシュノードを1台削除してみます。

cf03

以下のようにStatusが"deletting"になります。しばらく待つと完全に削除されます。

cf04この状態でconfig get clusterコマンドを実行すると、0002のキャッシュノードが削除され、0001と0003がクラスタに所属しているという情報が返ってきます。

config get cluster
CONFIG cluster 0 141
3
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com|172.31.22.213|11211 
smokeycache.16bbhn.0003.apne1.cache.amazonaws.com|172.31.3.104|11211

END

以上から、アプリケーションとしては、コンフィグレーションエンドポイントに接続してconfig get clusterコマンドを実行すれば、そのタイミングでキャッシュクラスタに所属しているノードの情報が取得出来ます。このためアプリケーションではキャッシュノードの増減を意識すること無く使うことが出来ます。これがオートディスカバリの機能です。

そして今回の新機能によって、AZを分散した形でオートディスカバリが使えるようになりました。これはアプリケーションの可用性を高める上で大きな機能拡張では無いでしょうか。

ElastiCache Cluster Client

このオートディスカバリを活用するために、AWSではElastiCache Cluster Clientというライブラリが用意されています。

これらのライブラリを使うことで、アプリケーション側で複雑な分散処理を書くことなく、手軽にオートディスカバリのメリットが享受出来ますので、活用をお勧めします。

なお、ElastiCache Cluster Clientが使えないなどでオートディスカバリ機能を有効活用出来ない場合には、アプリケーションとしてキャッシュノードを複数指定するような実装が必要です(参考:Connecting to Cache Nodes Manually)

前述の通りコンフィグレーションエンドポイントはキャッシュクラスタに所属するキャッシュノードに紐付けられていますので、直接get/putすることも可能です。しかし紐つけするキャッシュノードの指定は出来ないため、どのキャッシュノードに対してget/putしているのかは分かりません。このためキャッシュしたはずのデータがヒットしない、というような状況が起こりえます。

コンフィグレーションエンドポイントはあくまでキャッシュノードの一覧を取得するためにのみ使用し、アプリケーションとしてはキャッシュノードのエンドポイントに対してget/putする、というのが正しい実装です。

まとめ

自分の認識が甘いところを、手を動かして学ぶのは大事だな、と改めて思った次第です。という感想です(笑)

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.